It looks like there unfortunately isn't a --porcelain (guaranteed not to change across git versions) version of git branch output like there is with git status? I'm wondering how to make the parsing resilient to multiple versions of git in the wild (including future versions). Of course, once I get around to #33 that could be a good long term solution. Another possibility while relying on CLI git, do you think it might make sense to use something like --format to specify a specific format? I'm not sure if that might be more resilient to change.

Another edge case to consider might be whether there is a way to ensure the pager is disabled on a per command basis here, so git doesn't try to run its output through a pager if there more lines of branches than it thinks will fit on the user screen. From the git branch documentation it appears that is the default, we might want to verify if it is automatically disabled somehow based on detecting whether STDOUT is a pipe or tty.

--format w/ pager forcibly disabled makes sense to me here!

Is this syntax fully POSIX compatible?

This was automatically flagged by the shell linter you have in the repo, can’t see the exact message any more but I believe it mentioned that this has been supported in Bash for decades

Clobbering the existing file variable could be problematic: it might not be obvious to a user that if they list branches, the previous file shortcuts that were displayed to them would stop. working. I suspect we need a second variable here (which unfortunately does add to implementation complexity, but I don't know a great way around that).

I was previously a very active user of scm_breeze (I definitely prefer the simplicity of scmpuff!) and fwiw it shared the same env var space between all numbered commands. It definitely wasn’t ideal but was pretty intuitive I think

Really appreciate these integration tests!